Well, I was believing stateless sessions were not handling any kind of association, but the documentation only writes about collections. Granted, I have almost never used a stateless session.

Does many-to-one works? If no, having only one-to-one supported would be a bit awkward.

I believe so - the project that I was working on where I came across the 1:1 bug was with a hierarchy that had a many to one relationship that was being loaded correctly.
I have added an object with a many-to-one relationship and a test for that to my code, should I update the pull-request with it?

No, no need. Ideally such a test should already exist somewhere in NHibernate tests, but I have not checked.

I think the mappings and tests in NH1574 show retrieval of an object with a many-to-one association (SpecializedPrincipal). (StatelessTest.cs)

From my point of view the changes are correct and consistent with other places where associations are involved.

Some notes of interest (which do not infirm this PR validity overall):

I have checked the many-to-one case: it does not work by default, because the association is loaded as a proxy and stateless session does not allow initializing a proxy. So it fails as soon as an access to a member of the association other than the id is done.

The one-to-one case is special in this respect, because it cannot be proxified from the non-constrained side. (It does not know if it exists without querying its table, so it loads it instead.) So from the non-constrained side, it is always directly loaded, instead of being proxified.

But the constrained side fails like a many-to-one by default.

Doing more checks, if the many-to-one is set as lazy="false", it does work (even without this PR), so we can consider that supporting accessing a non-constrained one-to-one on an entity loaded from a stateless session is consistent with the many-to-one case, because a non-constrained one-to-one is non lazy by default.

Need async tests generation.

Hi @seamus-hoban. Please drop the last commit and regenerate the async tests. To regenerate async tests:

On windows:

1. Run ShowBuildMenu.bat
2. Press H on keyboard (option "H. Generate async code (Generates files in Async sub-folders)").
3. Wait the tool to complete
4. Commit and push generated code

On other platforms (mono):

1. Navigate to ./Tools folder
2. Run nuget install
3. Navigate to ./src folder
4. Run mono ../Tools/CSharpAsyncGenerator.CommandLine.0.8.2/tools/AsyncGenerator.CommandLine.exe
5. Wait the tool to complete
6. Commit and push generated code

Okay, will do sorry.

Just pushing the reverted test file now as I've errors on the ShowBuildMenu options above.

"unable to load one or more requested types' from Nant.NUnit2Tasks.dll.

And

"Msbuild failed when processing the file 'C:\Projects\nhibernate-core\src\NHibernate\NHibernate.csproj' with message: MSB0001: Internal MSBuild Error: Missing resource ''"

The first error is usual (at least on my machine) and does not prevent the task to execute. I do not know about the second one, I have never seen it. Is your tooling up to date?

I have pushed the async regeneration.

Ok, I guess you have updated Visual Studio to its yesterday release, 15.6.3. With 15.6.2, it was still working. Now that I have updated it myself, it is broken.

generate-async:

     [exec] 11:37:31,760 INFO  CommandLine:0 - AsyncGenerator
     [exec]
     [exec] 11:37:32,072 INFO  AsyncCodeGenerator:0 - Generating async code started
     [exec] 11:37:32,650 INFO  AsyncCodeGenerator:0 - Opening project 'E:\Projets\nhibernate\nhibernate-core\src\NHibernate\NHibernate.csproj' started
     [exec] 11:37:33,374 FATAL CommandLine:0 - System.InvalidOperationException: One or more errors occurred while opening the project:
     [exec] Msbuild failed when processing the file 'E:\Projets\nhibernate\nhibernate-core\src\NHibernate\NHibernate.csproj' with message: MSB0001: Internal MSBuild Error: Missing resource ''
     [exec] Hint: For suppressing irrelevant errors use SuppressDiagnosticFailures option.
     [exec]    à AsyncGenerator.AsyncCodeGenerator.CheckForErrors(MSBuildWorkspace workspace, String itemType, ImmutableArray`1 supressFailuresPredicates, ILogger logger)
     [exec]    à AsyncGenerator.AsyncCodeGenerator.<OpenProject>d__8.MoveNext()
     [exec] --- Fin de la trace de la pile à partir de l'emplacement précédent au niveau duquel l'exception a été levée ---
     [exec]    à System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
     [exec]    à System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
     [exec]    à AsyncGenerator.AsyncCodeGenerator.<GenerateAsync>d__0.MoveNext()
     [exec] --- Fin de la trace de la pile à partir de l'emplacement précédent au niveau duquel l'exception a été levée ---
     [exec]    à System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
     [exec]    à System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
     [exec]    à AsyncGenerator.CommandLine.Program.Main(String[] args)

@maca88, do you have the issue too?

Thank you all!
Yeah 15.6.3 screws up any building from within Studio, but command line build is fine, but the AsyncGenerator stuff is as per your comment above. There's a thread on the developercommunity.visualstudio where are few others are affected.

Are you speaking of this thread? I think it is another (maybe related) trouble, since it has been opened before 15.6.3 release and is about project creation.

Otherwise could you link it?

I have not seen building in VS is broken too, I use primarily Rider. And well, I can still build with VS, even after having fully cleaned obj/bin folders in case it was reusing some assets compiled through Rider.

@hazzik, do you think this change is sufficiently mundane for going into 5.1.1? Or should it wait 5.2?

@fredericDelaporte This thread: https://developercommunity.visualstudio.com/content/problem/218326/after-1563-publish-fails-due-to-error-projectasset.html
I can't build within studio even after deleting bin and obj folders.

This is kind-a a bug, so fine if it will be in 5.1.1.

@fredericDelaporte Yes, it happened also to me after the upgrade. The solution was to upgrade the Microsoft.Build package to the latest version as there is a bug with the older MSBuild. I released a new version 0.10.0, that includes the upgrade of Microsoft.Build.